<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Concept: Pattern</title>
<meta name="uma.type" content="Concept">
<meta name="uma.name" content="pattern">
<meta name="uma.presentationName" content="Pattern">
<meta name="element_type" content="concept">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_0YJvUMlgEdmt3adZL5Dmdw"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Concept: Pattern</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/concept.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">A generalized solution that can be implemented and applied in a problem situation (a context) and thereby eliminate one or more of the inherent problems.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html" guid="_we3F4ACpEdu8m4dIntu6jA">Abstract Away Complexity</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html" guid="_0fshwMlgEdmt3adZL5Dmdw">Design the Solution</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/roadmaps/how_to_adopt_evolutionary_design_7CA256E4.html" guid="_irQiEOCsEdynptYdmll41Q">How to Adopt the Evolutionary Design Practice</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Software Reuse</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h4>
    Origins
</h4>
<p>
    The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. He has
    written widely on the subject of applying patterns to the design and construction of towns and buildings. Two of his
    books, <em>A Pattern Language</em> [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html" guid="__nHToFndEd2EdJKkAyeBng">ALE77</a>] and <em>The Timeless Way of Building</em> [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html" guid="__nHToFndEd2EdJKkAyeBng">ALE79</a>] have had the greatest impact on the software community and the adoption of
    software patterns for the design of software. His concepts of patterns and pattern language provide a model for the
    capture of software design expertise in a form that can then be reapplied in recurring situations.&nbsp;
</p>
<h4>
    A definition of patterns
</h4>
<p>
    Today, the most commonly used definition of software patterns is from [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html" guid="__nHToFndEd2EdJKkAyeBng">GAM95</a>]:
</p>
<blockquote>
    <p>
        "A design pattern describes the problem, a solution to the problem consisting of a general arrangement of objects
        and classes, when to apply the solution, and the consequences of applying the solution."
    </p>
</blockquote>
<p>
    This definition often serves only as a starting point, however. A richer definition, based on Alexander's work, is
    offered by Gabriel in his book, <em>A Timeless Way of Hacking</em> [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html" guid="__nHToFndEd2EdJKkAyeBng">ALU03</a>], in which each pattern is a three-part rule that expresses relationships
    among a certain context, a certain system of forces that occur repeatedly in that context, and a certain software
    configuration that allows these forces to resolve themselves.
</p>
<h4>
    Describing patterns
</h4>
<p>
    It is commonplace to describe patterns&nbsp;using the&nbsp;format made popular by Erich Gamma and his three colleagues
    [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html" guid="__nHToFndEd2EdJKkAyeBng">GAM95</a>]. They have come to be known as the Gang of Four (GoF); therefore, their
    description is known as the <strong>GoF format</strong>. The GoF format uses the following keywords to describe
    object-oriented design patterns:
</p>
<ul>
    <li>
        <p>
            <strong>Pattern name and classification:</strong> Naming the pattern allows design to work at a higher level of
            abstraction, using a vocabulary of patterns. Gamma says that finding a good name is one of the hardest problems
            of developing a catalogue of patterns (see <strong>Pattern catalogues</strong> later in this section).
        </p>
    </li>
    <li>
        <p>
            <strong>Intent:</strong> An answer to questions such as: What does the pattern do? What problem does it
            address?
        </p>
    </li>
    <li>
        <p>
            <strong>Also known as:</strong> Other names for the pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Motivation:</strong> A concrete scenario that illustrates a design problem and how the pattern solves
            the problem.
        </p>
    </li>
    <li>
        <p>
            <strong>Applicability:</strong> Instructions for how you can recognize situations in which patterns are
            applicable.
        </p>
    </li>
    <li>
        <p>
            <strong>Structure:</strong> A graphical representation of the classes in the pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Participants:</strong> The responsibilities of the classes and objects that participate in the pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Collaborations:</strong> How participants collaborate to fulfil their responsibilities.
        </p>
    </li>
    <li>
        <p>
            <strong>Consequences:</strong> The results, side effects and trade offs caused by using the pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Implementation:</strong> Guidance on the implementation of the pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Sample code:</strong> Code fragments that illustrate the pattern's implementation.
        </p>
    </li>
    <li>
        <p>
            <strong>Known uses:</strong> Where to find real-world examples of the pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Related patterns:</strong> Synergies, differences, and other pattern relationships.
        </p>
    </li>
</ul>
<p>
    Although the GoF format is specifically intended for object-oriented development, you can use it, with slight
    modification, to address other software patterns. A more general keyword format for software patterns based on
    Alexander's principles uses keywords such as <em>problem</em>, <em>context</em>, <em>forces</em> and <em>solution</em>.
</p>
<h4>
    Pattern catalogs
</h4>
<p>
    To assist with the identification and selection of patterns, various classification schemes have been proposed. One of
    the early schemes, proposed by Buschmann and his associates, [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html" guid="__nHToFndEd2EdJKkAyeBng">BUS96</a>] uses three classifiers: granularity, functionality, and structured
    principles. Of those three classifiers, it is their granularity classifier that has remained popular. Granularity
    classifies patterns into three levels of abstraction:
</p>
<ul>
    <li>
        <p>
            <strong>Architectural patterns:</strong> Architectural patterns express the fundamental structure of a software
            scheme. Examples of architectural pattern include: layers, pipes and filters, and the model view controller
            pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Design patterns:</strong> Software architecture usually consists of smaller architectural units that
            are described by design patterns. The GoF pattern is an example of a design pattern.
        </p>
    </li>
    <li>
        <p>
            <strong>Idioms.</strong> An idiom is the lowest-level pattern, and it is specific to a programming language.
        </p>
    </li>
</ul>
<p>
    Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
</p>
<ul>
    <li>
        Structure
    </li>
    <li>
        Distributed systems
    </li>
    <li>
        Interactive systems
    </li>
    <li>
        Adaptable systems
    </li>
</ul>
<p>
    The following table shows the categorization of their architectural patterns.
</p>
<table cellspacing="0" cellpadding="2" width="85%" summary="Categories for Architectural Patterns [BUS96]" border="1" valign="top">
    <caption>
        <strong>Categories for Architectural Patterns<br />
        </strong>
    </caption>
    <tbody>
        <tr>
            <th scope="col">
                <div align="center">
                    <strong>Category</strong>
                </div>
            </th>
            <th scope="col">
                <div align="center">
                    <strong>Pattern</strong>
                </div>
            </th>
        </tr>
        <tr>
            <td>
                Structure
            </td>
            <td>
                <p>
                    Layers<br />
                    Pipes and filters<br />
                    Blackboard
                </p>
            </td>
        </tr>
        <tr>
            <td>
                Distributed systems
            </td>
            <td>
                Broker
            </td>
        </tr>
        <tr>
            <td>
                Interactive systems
            </td>
            <td>
                Model view controller<br />
                Presentation abstraction control
            </td>
        </tr>
        <tr>
            <td>
                <p>
                    Adaptable systems
                </p>
            </td>
            <td>
                <p>
                    Reflection<br />
                    Micro kernel
                </p>
            </td>
        </tr>
    </tbody>
</table>
<p>
    For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
</p>
<ul>
    <li>
        Creational
    </li>
    <li>
        Structural
    </li>
    <li>
        Behavioral
    </li>
</ul>
<h4>
    Pattern languages
</h4>
<p>
    In addition to the concept of patterns, Alexander also gave the software community the concept of a pattern language.
    The purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would
    allow those who work, study, or live in buildings to communicate effectively with the planners and designers of those
    buildings. Alexander explains that when using a pattern language:
</p>
<blockquote>
    <p>
        We always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller,
        always from the ones that create structure to the ones which then embellish those structures, and then to those
        that embellish the embellishments.
    </p>
</blockquote>
<p>
    In applying patterns in this way, Alexander advocated the use of generative pattern languages, ones that, given an
    initial context, would always lead to good design.&nbsp; Alexander&nbsp;states:
</p>
<blockquote>
    <p>
        Thus, as in the case of natural languages, the pattern language is generative. It not only tells us the rules of
        arrangement, but shows us how to construct arrangements - as many as we want - which satisfies the rules.
    </p>
</blockquote>
<p>
    In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas.
    The sequential application of patterns finds application in software design processes, both waterfall and iterative,
    that successively apply architectural patterns, and then design patterns, and, finally, idioms to design and implement
    a software system. Software processes, however, rely on the skills of the Architect and Developer roles to guide the
    application of patterns, rather than a generative pattern language.
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
